The technical field relates to transfer of data packet flow related state and context information in access networks.
Following documentation is regarded as state of the art:    [1] J. Kempf (ed), “Problem Description: Reasons for Performing Context Transfers Between Nodes in an IP Access Network” (RFC 3374);    [2] J. Loughney (ed),“Context transfer protocol”, IETF, Internet draft, October 2003;    [3] G. Kenward (ed), “General Requirements for context transfer”, IETF Internet draft, October 2002;    [4] R. P. Swale et al., “Middlebox Communications (MIDCOM) Protocol Requirements”, IETF RFC 3304;    [5] B. Carpenter et al, “Middleboxes: Taxonomy and Issues”, IETF RFC 3234, 2002;    [6] P. Srisuresh, “Middlebox Communications (MIDCOM) Architecture and framework”, IETF RFC3303;    [7] R. Hancock (ed): Next Steps in Signaling: Framework”, IETF Internet draft, October 2003;
For context transfer purposes, the organization IETF has developed the Context Transfer protocol (see references [1], [2], [3]). In these documents, the context is defined as the information on the current state of a service required to re-establish the service on a new subnet without having to perform the entire protocol exchange with the mobile host from scratch and Context transfer is defined as the movement of context from router or other network entity to another as a means of re-establishing specific services on a new subnet or collection of subnets.
In IP (Internet Protocol) access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. For example, Mobile IP networks allow a mobile node or an entire moving network to change the access router that provides the first IP layer hop seen from the mobile node or from a moving network's edge. When the mobile node changes access router (due to, for instance, mobility), there is a need to establish a new path, whose nodes should ideally provide similar treatment to the IP packets as was provided along the old routing path.
In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization and Accounting (AAA), header compression and Quality of Service (QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signalling flows from scratch. This process may in some cases considerably slow the process of establishing the mobile host on the new subnet.
During the fast handoff, state information has to be transferred between access routers. Examples of state information that could be useful to transfer are Authentication, Authorization and Accounting (AAA) information, security context, QoS properties assigned to the IP flow, header compression information, etc.
A possibility is to simply move all the context from one access router AR to the other access router of a selected access point after handover. Said mechanism works properly when handling single IP flows. However, drawbacks have been recognized concerning services and sessions wherein more than one flow is involved. For example, Multimedia sessions may involve several parallel IP flows, one for voice, one for video, and one for whiteboard. After a hand-over between two access points, it is not unusual that IP flows belonging to the same session are distributed on different radio interfaces of a terminal. In such a situation, the flows of a session are distributed on two access routers after the hand-over and associated context transfer. The context transfer must then be performed in both access routers, since there is no master access router that can assume responsibility for the session context. This would lead to a context synchronization problem since the session context may have to be renegotiated during a session. For example, the bandwidth of the session may be renegotiated.
The transfer of IP flow related state and context information is facilitated by the IETF Context Transfer protocol (see reference [2]).
The IETF MIDCOM working group (WG) has examined scenarios and defined protocols for IP networks that contain entities that perform functions apart from traditional layer 3 (L3) routing, so called middleboxes (MB) (see references [4], [5], [6]). A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and a destination host. Such middleboxes may require a context that is specific to the functions and services they perform. For instance, a Quality of Service scheduler may need to maintain some token bucket state associated with an IP flow (QoS context), a firewall may need to know about a security association of an IP flow (security context), etc. For the moment, it is possible to list 22 different kind of middleboxes that could be provided along an end-to-end path.
Middleboxes embed application intelligence within the device to support specific application traversal. Middleboxes supporting the Middlebox Communication (MIDCOM) protocol will be able to externalize application intelligence into Midcom agents. Therefore, Midcom agents are logical entities which may reside physically on nodes external to a middlebox, possessing a combination of application awareness and knowledge of middlebox function. A Midcom agent may communicate and interact with one or more middleboxes. Said Midcom protocol between a Midcom agent and a middlebox allows the Midcom agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the Midcom agent. Further, the Midcom protocol enables the, middlebox to perform its operation with the aid of Midcom agents, without resorting to embedding application intelligence.
The particular end-to-end path, along which some middleboxes may need context can traverse multiple operator domains. Herein, a domain or administrative (operator) domain is the collection of hosts, routers, middleboxes and the interconnecting networks managed by a single administrative authority or owner. The devices that operate in the same administrative domain share common security features that are administered across the domain. It is an issue how to distribute the context to the middleboxes that need the context, since the operator domain where the hand-over occurred may be unaware of the particular middleboxes that are located in another provider's or operator's domain.
As mentioned, there is a need of a coordination mechanism for the transfer of context for flows that belong to the same session.
One object with the technology disclosed herein is to offer a coordination mechanism for the handling of context associated to flows that belong to the same session.
In simple terms, a problem addressed by the technology disclosed herein is to define a context transfer procedure that meets the above requirements, and an object of the technology disclosed herein is to provide a solution to the stated problem.